Hypnosis - The 8 States of Unconsciousness (DamageWolf3D V2.0) Codex: STL of Damage Finland (Antti Lankila) AGA GrApHiCs: Bartosz Boruta a.k.a. Peek@IRC Testing hardware support: Peek (Thanks) Quality Assurance: *@* :) REQUIREMENTS: at least 68000 / OCS / .5MB CHIP, 1MB FAST / 1.2 (A500++) recommended 68030++ / AGA / 2MB CHIP, 1MB-xMB FAST PROBLEMS: A4000/040 - works only briefly. This applies to *all* lower processors too, but the mean time before the crash increases exponentially. This is a sudden engine jam - seems to occur even more likely when jumping. I am trying to kill this bug on top priority. KNOWN BUGS: A certain sized screen seem to be able to crash the machine sometimes - F8 enters a pixel-doubled mode, which seems more vulnerable on some occasions. The inside corners of walls fail quite pathetically 99% of time - a pixel-width slice of sky is displayed instead of the intended wall. Too near observation of walls (and sky) causes ceiling stripes (texture) to flood down, sky rendering blankouts, interesting mess and sometimes even Guru 5. Beware. The jumping reaches one pixel too high (ouch) ;) The dithering colours look a little weird at certain distances - hopefully it functions better on AGA. With ceiling disabled, a line-high piece of sky is rendered where it should not be. This occurs at certain directions only. FUTURE: A Game. Support for Graffiti chunky graphics card (yeah!). .. extensive support for other graphics cards .. PD -> Shareware? V1.0 - V2.0 developement info ignored: major rewrite - not relevant V2.0 - Still a fucking walkaround demo - "AGA" gfx ;) - released · Primary AGA texture file support · 128x128x8 textures. · 90 degrees vision. · ExtraHigh mazes · Sky (not that much of improvement after all :-) *** Some LeGaL stuff: This game is PD. No fees except a small copying fee is allowed. No distributions through PD companies without my permission (excluding Aminet collections and Fred Fish). I am not responsible for any losses of any kind of data that might, are or are not, caused by this program or any of the other files required for DamageWolf to operate, or supplied with this archive on the original state, which also means that you must kindly leave the archive intact thank you very much. Let me exclude Alla(s|h) who will nail me to the wall if I won't let him advertise his BBS. Phew. Now lets go to the traditional DMGWolf release information. The graphics for this engine have been drawn by Bartosz Boruta, boruta@omk.il.pw.edu.pl, Peek@IRC on #amigapl, #amiga and so on. These graphics obey an AGA palette and AGA iff form, but due to some problems, we are sticking on only the EHB-side colours yet. You might experiment with AGA colours yourself - tell us the results then, too. Basically, AGA colours work even on EHB and are realtime converted via dithering. I still don't own an 1200 and without the new Kickstart I would have gone mad supporting AGA; I did not have to write my own support system for 256c IFF files (to even see them). This Wolf3D clone leaves my HD without real beta-testing. So I am sorry for any at-the-moment-unknown bugs that exist. To run the Wolf3D succesfully, you need to follow the file hierarchy introduced in the archive. Each data file on your HD needs to be placed like they are placed in the archive. The dir tree looks something like this (only a brief example): current directory: tris (dir) nottriangle-hole.256 nottriangle-main.256 nottriangle-blah.256 nottriangle-lahb.256 nottriangle-ahbl.256 nottriangle-hbla.256 blue (dir) whiteblue1.256 whiteblue2.256 just_some_gfx (dir) blah blah texture 1.256 blah blah texture 2.256 blah blah texture 3.256 recalcscreen.ehb Scenery.chraw Wolf3D-BB.EXE MapEditor MAP etc.. A misplaced file can not be located by the engine. This will cause memory junk to be displayed instead of the desired texture (or blank zeros.. Can't remember ;). The Wolf will not crash even on case of all the files missing, but it won't look too exciting either. The Wolf3D, Mapeditor and MAP should reside at the example's Current Direcory. The Wolf3D assumes that the current directory used when the Wolf3D was run is the root directory for the Wolf3D's data files. The WMAP file is a script and should be at 'S:'. Wolf3D will not function from disks - it will be a HD only game. It will take about 3-5 M of disk space. The current version might still work - I don't know. To use it on disks is annoyingly slow at any rate. The gfx style owes a little to ROTT, DOOM, Heretic (and 99% of the Amiga clones around, too) and the person Arctangent (Thanks for letting us to use your gfx), whose textures were found on Aminet. I won't single any textures out out of the currently used gfx, because I have quite a huge library of textures for this ROTT clone, and the filenotes are there to tell everything needed (I hope they still remain). The 90° vision was something I added due to Wolfenstein3D, DOOM, Heretic and ROTT. Now DamageWolf looks much more like one of those. The actual view of our own eyes is about that 90° and so this attempts to mimick the real thing... Not! Sorry. The corners stretch the most unrealistic way and the floors sprain brilliantly strangely. Welcome to 90 degrees! :-) The Height/look-up'n'down routines were written after hours of ROTT experience. This also means that DamageWolf has no precalculated information except the most required; I removed about every one of the previously-essential precalculations and kicked in completely new realtime algorithms - more flexibility etc. you understand :-) The sky is my own implementation of both dimension stretches - normally the _NECESSARY_ Y-stretch is ignored. Looks damned ugly - just look at DOOM and Heretic or whatever! Why is that, it does not even optimize (or at least not very much). I hope you like Mountains that look a little more like they should. They are drawn-calculated by my gfxman. I wonder what this Wolf clone would have become if it wasn't for Bartosz Boruta, who kicked me hard enough (and /dcc'd his willpower every time necessary) to force me to do something serious. I hope you agree :-) I am not going to make any barriers for editing the Wolf3D (No, I am not gonna publish it under GNU however ;). This is why the gfx files are perfectly normal .iff format (This little improvement took damned two hours!), the will-be-samples will be replacible and this is also why a real map editor was made. I hope that you Amiga freaks will have fun making your own Talvisota Simulaattori and designing your own game (when I get it coded that is). The only real limit is that the palette of the iff files must be left intact. If you use our gfx, please give the credit to the appropriate persons too. Or what do you say, Bartosz? Only the mountain file is a special chraw file that can not be generated by the user, unless there is a good iff converting software. The format for that file is 320x256 ordinary chunky rotated 90/270 degrees, using our AGA palette (this file is AGA even tho the others are not, some pre-taste about what my AGA-EHB converter can really do ;). All KS2.0++ owner dudes, you may now happily bang your keyboard as much as you wish and it should still work ok at the end :-) .. It wasn't an A1200 keyboard bug, but a problem of KickStarts' different CIA timer settings (well well well). After I upgraded to 40.68 I was instantly faced with the same problem and I could finally solve it (blush). However, the A1200 keyboard still can't handle all of the simultaneous presses so don't blame me if you can't go forwards while pressing sidewalks, rotating, jumping and looking down etc. That's a hardware problem. I doubt if you can do all that at the same time either ;) Numeric keyboard controls: [ ] / * sidewalk left move forwards sidewalk right Jump 7 8 9 - turn left move forwards turn right Look upwards 4 5 6 + turn left move backwards turn right Look downwards 1 2 3 E turn left move backwards turn right ;open doors 0 . running mode And ... ramiga should make the turning keys do sidewalk, shift should make you virtually run, F10 will flip between OCS/AGA modes and F8 will toggle a pixel doubler on/off. The one between, F9, flicks one bit in memory that has no function at all. That's it I think. The final key assignment will be much like DOOM's. The WMAP file and MapEditor are files needed for mapediting. The former is a KS2.0++ script to edit a file (usage: WMAP ""). It will need slight editing (you are not likely to use the same path definitions that I do), but the basic idea should be the same. MapEditor is the actual map editor executable. Like the Wolf, it will attempt to load the gfx files to be able to display them during the editing of the map. The MapEditor.help deals with the editor more spesifically. I apologize for the proportionally large sizes of the executables and map files - shit happens. They all crunch VERY heavily, especially the map editor; what would it be, 5% left after lzx'ing I assume. :) Both are mostly nulls (Wolf3D uses bss hunks so I know about THAT, it is just that that I am lazy ;). The map editor might represent some difficulties for a newcomer. The hest help file is experience. I hope you will have a happy time examining the cryptic methods that are used to create a map with the editor ;) The Engine ---------- 1. Special section: Ray Casting enhancements in DamageWolf3D The actual casting is omitted as it is quite normal although very rayfiring based, but not so iterative however :-) The Ray Casting involves tracing quite far on some occasions. I'll tell you an optimation that helps especially when looking straight at the end of the maze where the outside is about nulls (and yet another of the casts has to travel there). If the first cast hits at distance, say, 50, then the second is only needed to be casted to that distance and not further. This is for the fact that even if something was found, it would be blocked by the first cast's results anyway. It is VERY likely that the cast that gave the wall coord last time returns the wall coord this time time too, and due to the ray-blocking feature, the second cast is not needed to be casted to the extreme backwaters of the map, but it can be cancelled at the point of the end of the first cast, thus, expensive processor time gets saved. This method is completely errorproof in results and still very useful. I also read that the floors can not be handled with ray casting. Perhaps not in the wall solving loop (it isn't even wise), but casting is a powerful tool to manage the floor anyway. As the floor in DamageWolfV2.0 uses no precalculated tables - simply because for all the heights and looking directions (angles and up/dward possibilities) there is and would not be enough memory - the V2.0's replacement routine to V1.6 is in fact based on ray casting. This is only for your curiosity :-). Compared to the wall's rendering loop it runs on almost equal speed! Even though the floor is much more tricky - imagine that walls is only a string of values that need to be stretched or shrinked so that the original contents fill a desired length. The floor is a (x,y) array of X * Y bytes where the same stretch takes its values from a line that goes thru this 2D array. So there is more with the rendering of the floors. I have been asked to tell about my C2P converter. So - this is for the interested people: The chunky to planar algorithm writes to a scrambled buffer (some c2p passes deleted), and 35% of the rest is completed with the CPU - the stillexisting optimized remains of the first sweep of c2p_020_fastram.a, having 6th and 7th planes support entirely deleted. The excretements of the processor are dumped to a asynchronous blitter task, which, without any futher notices, converts the rest in the background. The processor parts exists due to the faster Chunky buffer access as it is in Fast memory. That was it for the OCS. For the AGA mode, I use c2p_020_fastram.a's slightly clipped version (sorry, no blitter algorithm here). *** Enough. N-joy, have fun, explore. Hope it works on all the machines you people own :) .. If you have comments, suggestions or questions, just mail me. Any mail would be most welcome. Said in an irc script way...: /set cmdchars ./ .notify STL .notify Peek I am about to have an holiday, length of a week. Do not be surprised if there is no reply during 2x.10. After that time I will be firmly stuck in the computer class again. * STL / Damage --- Antti Lankila --- andezl@kastelli.otol.fi * * Peek --- Bartosz Boruta --- boruta@omk.il.pw.edu.pl * -STL